Methods and systems for coordinating pooled financial transactions

ABSTRACT

Methods and systems are provided for processing a financial transaction. A set of conditions is received that define circumstances for execution of the financial transaction. Funds are collected for each of a plurality of partial payments prior to satisfaction of the set of conditions, with at least two of the partial payments being collected from different persons. The collected funds are accumulated for support of the financial transaction until satisfaction or failure of the set of conditions.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a continuation of U.S. patent application Ser. No.10/391,502, entitled “METHODS AND SYSTEMS FOR COORDINATING POOLEDFINANCIAL TRANSACTIONS,” filed Mar. 17, 2003, the entire disclosure ofwhich is incorporated herein by reference for all purposes.

BACKGROUND OF THE INVENTION

This application relates generally to financial transactions. Morespecifically, this application relates to methods and systems forcoordinating pooled financial transactions.

There are numerous applications in which it is desirable for a group ofpeople to pool their financial resources and to use the pooled resourcestowards a financial transaction. This may be illustrated with a specificexample that is sometimes referred to in the Detailed Description of theInvention below when describing how certain aspects of the invention maybe implemented in specific embodiments. Consider the case of John, whohas learned that his father is terminally ill. John's father lives in adifferent country than John and John would like to visit his father, butis unable to afford the purchase of an airline ticket. There are variousrelatives who would be willing to provide financial support, but theirability to do so is complicated by the fact that they are geographicallydisperse, with some living in different countries than either John orhis father. The ability of the various relatives to pool their financialresources is thus further inhibited by the fact that those resources arenot even available in the same currency. There is a need for a simpleway to coordinate the purchase of the airline ticket among the variousparties.

Similar needs may arise in various other circumstances in which a groupof people wish to pool their financial resources. Accordingly, there isa general need to provide a simple mechanism for coordination of pooledfinancial transactions.

BRIEF SUMMARY OF THE INVENTION

Embodiments of the invention thus provide methods and systems forprocessing financial transactions that greatly simplify pooling offinancial resources among multiple people. Some embodiments make use ofan architecture that permits access to a host system that implementsmethods of the invention. The architecture, which may also be used forvarious other applications, may include direct interfaces withgeographically distributed transaction devices and may include variousremote interfaces, including an Internet interface, a DTMF interface,and/or a cable interface. Equivalent functionality is provided with eachof the interfaces, and the availability of a large number ofgeographically distributed transaction devices permits diverseinteraction with the host system, even in areas or by persons withouteasy access to one of the remote interfaces. The host system maintainscriteria that define when the transaction is to be executed or aborted,and coordinates the collection of partial payments made by differentpersons, thereby effecting the pooling aspect of the transaction.

In one specific set of embodiments, a method is provided for processinga financial transaction. A set of conditions is received at the hostsystem that define circumstances for execution of the financialtransaction. Funds are collected for each of a plurality of partialpayments prior to satisfaction of the set of conditions, with at leasttwo of the partial payments being collected from different persons. Insome cases, one of the partial payments may be made by the person whoestablishes the set of conditions. The collected funds are accumulatedfor support of the financial transaction until satisfaction or failureof the set of conditions.

There are various types of conditions that may be used. For example, inone embodiment, the set of conditions comprises a total transactionamount. In another embodiment, the set of conditions comprises a timelimitation. Still other types of conditions may be imposed, includingsome that rely on the occurrence or non-occurrence of an external event.There are also various ways in which the funds may be collected,including by charging a card account, such as from a credit card, debitcard, stored value card, and the like, and/or by receiving cash.

Upon satisfaction of the set of conditions, at least some of theaccumulated funds may be transferred to execute the financialtransaction, a process that may include performing a currency exchangeof the funds. In some instances, a notification that the accumulatedfunds have been transferred may then be provided. In addition, an excessof the accumulated funds that are unused may be refunded in someinstances. Such a refund may also be made upon failure of the set ofconditions to return unused accumulated funds.

In another specific set of embodiments, a method is also provided forprocessing a financial transaction. A set of conditions is received atthe host system that define a beneficiary to the financial transactionand circumstances for execution of the financial transaction. Prior tosatisfaction of the set of conditions, funds are collected for a firstpartial payment initiated at a first location and for a second partialpayment initiated at a different second location. A determination ismade whether to transfer the collected funds to the beneficiary bydetermining whether the set of conditions has been satisfied. The typesof conditions, methods for collecting funds, and actions taken aftersatisfaction or failure of the set of conditions are varied, and includethose mentioned above.

The methods of the present invention may be embodied in acomputer-readable storage medium having a computer-readable programembodied therein for directing operation of the host system. The hostsystem may include an input device, a communications system, aprocessor, and a storage device. The computer-readable program includesinstructions for operating the host system to process a financialtransaction in accordance with the embodiments described above.

BRIEF DESCRIPTION OF THE DRAWINGS

A further understanding of the nature and advantages of the presentinvention may be realized by reference to the remaining portions of thespecification and the drawings wherein like reference numerals are usedthroughout the several drawings to refer to similar components. In someinstances, a sublabel is associated with a reference numeral and followsa hyphen to denote one of multiple similar components. When reference ismade to a reference numeral without specification to an existingsublabel, it is intended to refer to all such multiple similarcomponents.

FIG. 1A is a block-diagram representation of a partial architecture forimplementing pooled transactions in accordance with an embodiment of theinvention;

FIG. 1B is a schematic illustration of a device that may be used tocollect and/or pay funds in accordance with embodiments of theinvention;

FIG. 2 is a flow diagram illustrating a method for processing afinancial transaction in accordance with an embodiment of the invention;

FIGS. 3A and 3B are simplified exemplary screen diagrams that may bedisplayed on a display screen while initiating a financial transactionin accordance with an embodiment of the invention; and

FIG. 4 is a schematic illustration of a computer system on which methodsof the invention may be embodied.

DETAILED DESCRIPTION OF THE INVENTION

Embodiments of the invention provide methods and systems for processingpooled financial transactions. As used herein, a “pooled” financialtransaction includes contributions to the financial transaction from atleast two different persons. In some instances, the pooling may occurover a period of time, as well as through multiple persons. One exampleof such an instance is where one of the persons makes contributions atdifferent points in time as that person's financial resources becomeavailable, such as through receipt of wages or other payments.Coordination of such pooled financial transactions is achieved inembodiments of the invention by use of a money-transfer architecturethat has the capacity to be accessed in geographically disperse areas.

An illustration of one possible architecture that may be used to enablesuch embodiments is illustrated with the schematic diagram in FIG. 1A.Coordination of the pooled financial transaction is effected by a hostsystem 100, which is in communication with one or more interfaces thatmay be used for interaction. The geographical dispersion for access tothe host system 100 may be effected by using transaction devices 120that are geographically distributed. Each transaction device 120 may beconfigured as a stand-alone device for collecting information fordefining the pooled financial transaction and the conditions under whichit is to be executed, in addition to performing other functions. Theconnections between the host system 100 and the transaction devices 120may be maintained with any communications protocol known to those ofskill in the art, including electronic, optical, and othercommunications protocols. Because of the sensitive nature of thefinancial information that may be exchanged, such communicationsprotocols generally incorporate strong encryption schemes.

In other instances, the system may permit collection of relevantinformation by the host system 100 with an interface that is itselfaccessible from geographically disperse locations. Examples ofinterfaces that may be used include an Internet interface 128, whichmay, for example provide a World Wide Web interface for staging thepooled transaction. Another interface that may be provided is a DTMFinterface 132, which includes a processor for decoding DTMF tones from atouch-tone telephone. Such tones may be used in combination with arecorded-voice interface to collect information for staging the pooledtransaction. A further interface that may be provided is a cableinterface 136, which includes a processor for decoding cable signals forstaging the pooled transaction.

The transaction devices 120 and other interfaces permit directinteraction with the host system 100 by persons involved with the pooledtransaction. Indirect interaction is also possible, such as by using afinancial institution 124 as an intermediary, but this is not requiredin embodiments of the invention. In such instances, the financialinstitution 124 is interfaced with the host system 100. Such anarrangement permits the financial institution 124 to accept fundstransferred from the host system 100 as part of the pooled transactionand/or to provide funds to the host system 100 in accordance withinstructions from one of the persons involved with the pooledtransaction.

Merely by way of example, the use of different components of thearchitecture may be illustrated with the example of John seeking topurchase an airline ticket outlined in the Background of the Invention.In this example, John is a customer 104 who wishes to make arrangementsby which other family members may contribute to his purchase of anairline ticket. Each of the family members who makes a contribution isidentified in FIG. 1A as a contributing party 116 and the airline thatis to receive the funds as part of the transaction is identified as thebeneficiary 108. In FIG. 1A, customer John 104 stages the pooledtransaction through interaction with one of the transaction devices120-1, although it may be staged through any of the other interfaceswith the host system 100. A first of the contributing parties 116-1interacts with a second of the transaction devices 120-4 to submit hiscontribution. The first and second transaction devices 120-1 and 120-4may be geographically separate, even being in different countries and/oron different continents. A second of the contributing parties 116-2instead interacts with the host system 100 through the Internetinterface to submit his contribution.

Each of these contributions may be obtained in different ways, dependingon the instructions provided by the contributing parties 116 when theymake their contributions. In some instances, their contributions may beprovided by specifying financial-account information and an amount to bedebited from the account. In such instances, the host system 100 uses aninterface with one of the financial institutions 124 to debit the amountand apply it to the transaction. The interface with the financialinstitutions 124 may also be used to execute the transaction bycrediting a specified account at a financial institution 124. This isparticularly convenient in the case of John's purchase of an airlineticket since the beneficiary 108 is not a natural person. Rather thanhave the airline send a representative to a specific location toretrieve payment, it may be deposited directly into an account of theairline with instructions to credit it to the specific ticket purchase.For this reason, FIG. 1A shows the beneficiary interacting directly withone of the financial institutions 124-3.

The specific interactions of the customer 104, contributing parties 116,and beneficiary 108 with the system shown in FIG. 1A are merelyexemplary. Different combinations of interactions may be more suitablefor other types of pooled financial transactions, and are intended alsoto be within the scope of the invention. Furthermore, the arrangementillustrated schematically in FIG. 1A may be viewed as a portion of alarger communications infrastructure. Such a communicationsinfrastructure provides communications interconnections and protocolsfor exchanging data among a variety of devices and institutions, inaddition to those identified in FIG. 1.

There are numerous different structures that may be used for thetransaction devices 120 indicated in FIG. 1A. Examples of such systemsare described in detail in copending, commonly assigned U.S. patentapplication Ser. No. 10/206,661, entitled “MONEY TRANSFER SYSTEMS ANDMETHODS FOR TRAVELERS,” filed Jul. 26,2002 (“the '661 application”), theentire disclosure of which is herein incorporated by reference for allpurposes. For example, local terminals may be used to accept cash,credit cards, checks, debit cards, stored value cards, smart cards, andthe like as part of initiating the pooled transaction. The transactiondevice may also include payout functionality that permits it to print acheck, print a money order, credit a stored-value card, and the like.This payout functionality may be used in instances where execution ofthe pooled transaction comprises performing such a payout, with thepayout being collected at the transaction device 120. Examples of suchterminals are described in the following commonly assigned applications,the entire disclosures of which are incorporated herein by reference forall purposes: U.S. Prov. Pat. Appl. No. 60/147,889, entitled “INTEGRATEDPOINT OF SALE DEVICE,” filed Aug. 9, 1999 by Randy J. Templeton et al.;U.S. patent application Ser. No. 09/634,901, entitled “POINT OF SALEPAYMENT SYSTEM,” filed Aug. 9, 2000 by Randy J. Templeton et al.; U.S.patent application Ser. No. 10/116,689, entitled “SYSTEMS AND METHODSFOR PERFORMING TRANSACTIONS AT A POINT-OF-SALE,” filed Apr. 3, 2002 byEarney Stoutenburg et al.; U.S. patent application Ser. No. 10/116,733,entitled “SYSTEMS AND METHODS FOR DEPLOYING A POINT-OF-SALE SYSTEM,”filed Apr. 3, 2002 by Earney Stoutenburg et al.; U.S. patent applicationSer. No. 10/116,686, entitled “SYSTEMS AND METHODS FOR UTILIZING APOINT-OF-SALE SYSTEM,” filed Apr. 3, 2002 by Earney Stoutenburg et al.;and U.S. patent application Ser. No. 10/116,735, entitled “SYSTEMS ANDMETHODS FOR CONFIGURING A POINT-OF-SALE SYSTEM,” filed Apr. 3, 2002 byEarney Stoutenburg.

One basic structure for the transaction device is shown schematically inFIG. 1B. The components shown may form part of a device that is operatedby a clerk in accordance with instructions from a customer, or may bepart of a self-service device in which the customer enters instructionsdirectly. Regardless of how the transaction device 120 is configured foroperation, it may include a controller 150 that may communicate withvarious component devices such as a card reader 158, a card writer 160,a card issuer 162, a cash issuer 164, a check printer 166, and a cashreceiver 168. The transaction device 120 may include some or all ofthese devices.

The card reader 158 permits easy entry of customer information when thecustomer 104 has a card that contains identifying information common tomany transactions, such as the customer's name, identification number,and the like. These may be used to populate a transaction screen 300,such as the one described below. Similarly, such an identification cardmay be used with the card reader by contributing parties 116 and/orbeneficiaries 108 to simplify providing identification for participationin the pooled transaction. The card reader 158 may also be used toextract information from credit cards, debit cards, smart cards, storedvalue cards, and the like in embodiments where the customer 104 or othercontributing party 116 wishes to use those instruments as a source offunds for a partial payment towards the pooled transaction. The cardwriter 160 similarly permits information to be encoded and stored on avariety of similar types of cards. This capability permits thetransaction device to pay out funds in accordance with the pooledtransaction in some embodiments by adding value to a stored-value card,smart card, and the like. In some cases, cards may be issued to thecustomers 104, contributing parties 116, and/or beneficiaries 108 usingthe card issuer 162. For example, a customer card may be issued as partof a registration process of the customer 104, contributing party 116,or beneficiary 108, permitting that person to use the card rather thanre-enter identification information for later transfers. The card issuer162 may also be used to issue cards when making payments to recipientsin the form of stored value cards, smart cards, cash cards, and thelike. These may then be used at other transaction devices 120 or ATMs towithdraw the funds.

The cash receiver 168 may be used to receive funds from the customer 104and/or contributing parties 116 in accordance with partial payments thatthey make. Similarly, the cash issuer 164 may be used to dispense cashdirectly to the beneficiary 108 after the identity of the beneficiary108 has been confirmed, such as by having an identification card read bythe card reader 158 and entering a personal identification number. Cashpayouts may also be made by using the card reader 158 and cash issuer164 in combination to redeem value from a card having stored value.

The transaction device 120 may also include connections for interfacingwith peripheral devices. For example, a PDA interface 170 may permit aPDA device to be coupled to the transaction device 170, allowinginstructions for the pooled transaction to be made directly from thecustomer's PDA, which may conveniently be preprogrammed with variousinformation relating to the transaction, such as account numbers,information on the beneficiary 108, and the like. The PDA interface 170may similarly be used by contributing parties 116 to provideidentification and account information for submitting a partial payment,and by beneficiaries 108 to provide identification and accountinformation for receiving funds in accordance with the pooledtransaction. Connections for interfacing with other types of peripheraldevices may also be included to offer as much versatility as possible tocustomers 104, contributing parties 116, and beneficiaries 108 ininteracting with the system.

The functionality provided by the transaction devices 120 may in largemeasure be reproduced with the alternative interfaces, i.e. through theInternet interface 128, DTMF interface 132, and cable interface 136. Insuch cases, identification information from cards, such as credit cards,debit cards, smart cards, stored-value cards, and the like, is providedthrough the interface rather than the card itself Applicable debits andcredits in accordance with the pooled transaction are performed throughinterfacing with the financial institutions 124 to apply those debitsand credits to respective accounts held at the financial institutions.

Regardless of the type of interface used by the various parties, thepooled transactions may be effected in similar ways. Examples oftransactions effected with the arrangement shown in FIG. 1A are providedby the flow diagram shown in FIG. 2. In this embodiment, the pooledtransaction is initiated by the customer 104, who provides relevantinformation to define the pooled transaction at blocks 204, 208, and212. This information may be provided at a transaction device 120 asindicated in FIG. 1A, or through any of the other interfaces. Generally,at least three pieces of information are provided in defining the pooledtransaction, including beneficiary information at block 204, a totaltransaction amount at block 208, and conditions for execution of thetransaction at block 212. In an alternative embodiment, the conditionsmay instead be partially or fully specified by the beneficiary 108instead of by the customer 104. After the transaction information hasbeen entered, the customer 104 may be provided with a transactionidentifier that he may then communicate to contributing parties 116 fortheir use in identifying the pooled transaction.

The beneficiary information provided at block 204 may take the form ofproviding the name of the beneficiary, a known identification number, orsome other identifying information. The use of known identificationnumbers may be particularly useful for large-volume parties, such ascorporations. As such, in the example of John seeking the purchase of anairline ticket, the identification of the beneficiary as the airline maybe provided by specifying an identification number provided by theairline. A large beneficiary may have multiple identification numbersthat correspond to different departments, such that the specificidentification number provided permits more directed targeting of thepooled transaction when it is executed.

The total transaction amount provided at block 208 is used to define theamount of money to be transferred when the transaction is executed. Itis possible in some instances for more money to be collected fromcontributing parties 116 than is actually required for the transaction.This is evident, for example, in the case of John, where multiplerelatives may make contributions, being unaware of the size ofcontributions made by others. Since the airline ticket is for a fixedprice, only that amount should be transferred to the airline whensufficient funds have been accumulated; the excess collected funds maybe refunded as described further below. In some instances, specificationof the transaction amount may include specifying the currency for thetransaction amount, particularly where partial payments may be made inmultiple currencies.

The execution conditions provided at block 212 are used to define thecircumstances under which the transaction is to be executed and/or is tobe aborted. In some instances, such as the example of John, execution ofthe transaction may be desired as soon as a minimum level of accumulatedfunds have been reached. In other instances, it may be desirable toplace a time limit on when the transaction is executed, irrespective ofhow much money is collected. This may be suitable, for example, in anembodiment where the pooled transaction is to be used for a charitablefund-raising event. In such an instance, the execution condition servesto define a cutoff for the fund-raising period, during which it isdesired to collect as much money as possible, not to work towards a goalof a specific level of funds. Defining circumstances under which thetransaction is to be aborted may be useful, for example, in applicationswhere there is some time sensitivity to the transaction. This is alsoevident in the example of John, who may wish to require that the cost ofthe airline ticket be reached within two weeks, beyond which he will nottravel.

In some embodiments, the execution conditions may be subject to changeto respond to evolving circumstances. For example, the customer 104 mayhave the capability of changing the time limit, changing the amount thatis to be collected, changing the designation of the beneficiary, and thelike. In some instances, the capacity of the customer 104 to change theconditions may be subject to controls to avoid manipulation of thesystem to defraud contributing parties 116 through the use of unbridleddiscretion by the customer 104.

The information provided at blocks 204, 208, and 212 is not exhaustiveand additional information may also be provided in some embodiments. Forexample, while in many instances contributions towards the pooling maybe accepted from anyone willing to make a contribution, in otherinstances limitations may be imposed on who acceptable contributingparties are. Such a feature could be used, for example, where Johninstead wishes to raise funds to purchase a vacation package for hismother and wants to ensure that his mother does not contribute. Theability to specify contributing parties may also be used to simplifymaking the contribution for those parties. For example, if Mr. Smith ispreidentified as a contributing party on two different pooledtransactions, he may automatically be presented with options tocontribute to those transactions when he is identified by the hostsystem 100. This feature may thus avoid the need for the customer tocommunicate specific transaction identifiers to contributing parties116, thereby reducing the possibility of errors resulting from failingto receive the identifiers, mistranscribing them, or other such errors.

Once the pooled transaction has been defined by the customer 104,contributions may be made and accumulated towards the transaction. Suchcontributions may be made by the customer 104 himself, may be made bycontributing parties 116 that have been specifically identified by thecustomer 104, or may be made by any contributing party 116 to whom thetransaction identifier has been communicated. Thus, at block 216 of FIG.2, a check is made to determine whether a partial payment is being madeby the customer 104, and at block 224, a check is made to determinewhether a partial payment is being made by a different contributingparty 116. In many instances, these checks will be performed in the samefashion, with the customer 104 or contributing party 116 providinginformation to identify the transaction and providing funds foraccumulation towards the transaction. Blocks 216 and 224 are providedseparately, however, to emphasize the possibility that a partial paymentby the customer 104 at block 216 may be integrated with the procedurefor setting up the pooled transaction, while partial payments by acontributing party 116 at block 224 are generally made only after thepooled transaction has been set up by the customer 104. In particular, afield may be provided on the interface for the customer 104 to enterpartial payment information while he is providing the transactiondetails collected at blocks 204, 208, and 212. An example of such afield is provided below in the discussion of FIG. 3A.

If the customer 104 makes a partial payment at block 216, funds for thatpartial payment are collected at block 220. Similarly, if a contributingparty 116 makes a partial payment at block 224, funds for that partialpayment are collected at block 228. In some embodiments, only a portionof the partial payment is credited towards the pooled transaction, witha small amount being retained in the form of a service fee. In someembodiments, a receipt may be also be provided when a contribution ismade, either by the customer or by the contributing party. Such afeature may be especially desirable where the contribution qualifies fora tax deduction, with the receipts provided to each party making acontribution serving as proof of the tax-deductible payment. Inaddition, in some embodiments, collection of funds for a partial paymentat block 228 may prompt a notification to be sent to the customer 104.Such a notification may help keep the customer 104 well apprised of thestatus of the collections, and may in some instances identify thecontribution party while in other instances will maintain the anonymityof the contributing party. The funds collected at blocks 220 and 228 arecollected prior to satisfaction of the conditions established at block212. There are several advantages to collecting the funds prior tosatisfying the conditions. For example, collection at this time ensuresthat the funds are available for execution of the transaction as soon asthe conditions for execution have been met. The alternative ofcollecting after the conditions have been met runs the risk thatcommitted funds may have become unavailable and that actual execution ofthe transaction will not be possible.

A check is made at block 232 to determine whether the conditions forexecution of the pooled transaction have been met. If so, thetransaction is executed by transferring the funds identified at block208 to the control of the beneficiary 108 at block 236. This may beaccomplished by the host system 100 providing instructions to one of thefinancial institutions to credit an identified account with the funds,or by designating the funds as eligible for recovery by the beneficiary108. In such instances, the beneficiary 108 may then collect the fundsby providing suitable identification through any of the interfaces withthe host system 100, including at a transaction device 120 or throughone of the remote interfaces, and providing instructions for payment.Such payment may include payment in cash, payment in the form of astored value card, issuance of a check, credit to a specified account,etc. Often, the transfer of funds at block 236 will be accompanied byproviding a notification of the transfer to the customer 104 and/orbeneficiary 108. Such notification may be provided by any convenientmethod, including sending of an email message, a recorded telephonemessage, a postcard, and the like.

If the amount of the transaction is less than the amount of fundsaccumulated from different sources, a refund may be provided at block244. In some instances, the amount refunded is less that the excessfunds to account for collection of a service charge for the refund.Also, the refund may be made to different parties according to a defaultprotocol or according to a protocol established by the customer 104 whenthe pooled transaction was initiated. For example, the excess funds maybe refunded entirely to the customer 104, may be refunded to anotherspecifically designated person, may be refunded to each of thecontributing parties 116 in proportion to their contributions, etc.

A check is made at block 240 to determine whether specified failureconditions for the pooled transaction have been met, such as wouldrequire that the transaction be aborted in accordance with instructionsspecified by the customer 104 at block 212. If those conditions havebeen met, such as by passage of a predetermined period of time, withoutthe conditions for execution having been met, the collected funds may berefunded at block 248. Similarly to the refund provided at block 244,the amount returned may be less than the full amount collected toaccount for collection of a service charge. Also, the parties to whomthe refund is made may differ according either to a default protocol ora protocol established by the customer 104. The funds may be refundedentirely to the customer 104, may be refunded entirely to anotherspecifically designated person, may be refunded to each of thecontributing parties 116 in proportion to their contributions, etc.

The method continues over time to await partial payments from thecustomer 104 and/or other contributing party 116. Each time a partialpayment is made, at least some of the collected funds are accumulatedfor support of the financial transaction. This continues until eitherthe conditions for execution or the conditions for failure of thetransaction have been met. The fact that the method proceeds over timealso highlights the fact that pooling of resources may arise both bypooling resources from a plurality of persons, and by pooling resourcesfrom a single person over time. The pooling by a single person over timepermits partial payments to be made by that person at different pointsin time as funds become available, such as through periodic wagereceipts. Such pooling over time may thus be used to provide a layawayor similar type of savings program for that person. In some embodiments,the time pooling by a single person is performed in combination withpooling by a plurality of persons.

In some embodiments, the pooling capabilities provided according toembodiments of the invention may be combined with a variety of otherfinancial-services capabilities, such as with the money-transfercapabilities discussed in the '661 application. For example, thecombination of such systems could be used by a traveler to coordinatethe use of funds while traveling through different countries. Forexample, a European traveler could use the system to replenish anaccount with unused funds in British pounds while traveling in theUnited Kingdom, and later extract funds in euro when traveling in otherparts of Europe.

Implementation of the method described with respect to FIG. 2 may beillustrated with the screen shots shown in FIGS. 3A and 3B. These screenshots are examples of what may be shown on a transaction screen 300 thatforms part of a transaction device or may be shown on a local monitorfor the customer 104 when the customer 104 uses one of the remoteinterfaces. FIG. 3A provides an example of a screen that may be used bythe customer 104 to enter information defining the pooled transaction.For purposes of illustration, the screen is shown in simplified form,and the specific fields shown are not intended to be exhaustive, butrather to illustrate how information regarding the pooled transactionmay be received. In embodiments that use other interfaces that do notprovide visual screens, such as with a DTMF interface 132, equivalentinformation may be conveyed through a menu of recorded voice messages,with DTMF responses by the customer 104 being used to collect thedesired information.

The screen is shown in two parts. The top part provides fields forentering particulars of the transaction and the bottom part providesfields for entering conditions upon which the transaction is to beexecuted or aborted. In the top portion, the total amount of thetransaction may be entered at field 304. As previously mentioned, thisspecifies the amount of money actually to be transferred. In cases wherethere is no predetermined amount, so that all of the accumulated fundswill be transferred, instructions may be provided to enter “ALL”or someequivalent designation. Provision for specifying the currency in whichthe amount to be transferred is expressed may be provided with adrop-down menu 306 such as shown, or with an equivalent feature. A field308 is also provided for identification of the beneficiary 108, whichmay be provided in terms of a name or known identification number aspreviously described.

Some of the fields may comprise optional fields, which may be selectedin the illustrated embodiment by activating a check box 301. Otherfields may provide alternatives to be selected, as indicated through theuse of radio buttons 302 in the illustration. An example of an optionalfield is field 310, which permits entry of a partial payment amount bythe customer 104, such as discussed in connection with block 216 of FIG.2. The partial payment amount may be accompanied by field 312 foridentifying the source to be used for collecting the partial paymentamount, as at block 220 of FIG. 2. In many instances, this source willspecify an account, such as by providing routing and account numbers toidentify a specific account at a financial institution 124. In otherinstances, provision may be included for indicating that cash will beprovided, such as through a cash receiver 168 at a transaction device120, that a credit, debit, stored-value, or other type of card will beprovided to a card reader 158 at a transaction device 120, or that someother mechanism accepted by the system for payment will be provided.

An example of a field that includes alternatives to be chosen is shownfor the identification of where funds are to be transferred uponsatisfaction of the transaction conditions. It is possible to selectfrom a predetermined list 314 of transaction-device locations, as shownwith a drop-down menu, or to enter a different destination in field 311.The alternative destination specified in field 311 may identify anaccount, such as by providing routing and account numbers. In someinstances, this field 311 may be populated automatically by the systemupon identification of the beneficiary 108, particularly where thebeneficiary 108 is a person registered with the system and haspreviously provided account information.

An optional field 316 may also be provided for text that the customer104 wishes to accompany the transaction when it is executed. In theexample of John seeking to purchase an airline ticket, this field may beused to specify a ticket number provided by the airline to which thefunds are to be applied when they are received.

The examples of fields in FIG. 3A is not intended to be exhaustive andother limitations on the transaction may be specified in someembodiments. For example, provision could be made to limit the amountsprovided with each separate contribution by a contributing party. Suchlimits could specify a minimum amount that must be provided to make acontribution and/or could specify a maximum amount that would beaccepted as a contribution.

The fields in the bottom portion of the screen 300 illustrate differenttypes of conditions that may be implemented, but the illustrations ofthem are not intended to be exhaustive and other types of conditions maybe imposed in alternative embodiments. Each of the conditions isoptional, and may thus be selected with respective check boxes 301. Afirst type of condition that may be implemented is a time-basedcondition. Such a time-based condition may be implemented by requiringthat funds be collected prior to a specified date, as indicated withfield 318, or that they be collected within a certain specified timeperiod. A second type of condition that may be implemented is afunds-based condition. Such a funds-based condition may be implementedby requiring that a certain level of funds be collected, as indicatedwith field 320. Usually, a funds-based condition will specify thecurrency in which the condition is to be applied, such as by providing adrop-down menu 322 for specification of the currency. In otherembodiments, a funds-based condition may be more specific, requiring,for example, that certain levels of funds be collected from specificcontributing parties 116. Still other types of conditions may be imposedin other embodiments, some of which may be based on the occurrence ofexternal events. For example, in an embodiment, the pooled transactionmay be intended for the purchase of a home and a condition may beimposed for execution of the transaction that a relevant interest ratebe below a certain value at the time the required funds are collected.Still other external events may be used to provide conditions, such asstock indices, and the like.

Field 324 provides an example of a failure condition, the occurrence ofwhich may trigger abortion of the transaction at block 240 of FIG. 2. Inthe illustrated example, the failure condition is satisfied when therequired funds level has not been reached by a specified date. It is,thus, an example of a time-based failure condition. Other failureconditions may include funds-based failure conditions, as well asfailure conditions that are dependent on the occurrence ornon-occurrence of external events. The screen 300 includes an indicationthat there may be a service charge imposed if satisfaction of thefailure condition results in a refund to the customer 104 and/orcontributing parties 116.

Once the customer has completed the fields on the screen 300 to definethe pooled transaction and conditions for its execution and/or failure,a submission button 326 may be activated to convey the information tothe host system 100. The host system 100 may then generate a receipt 350for presentation on the display, such as shown in FIG. 3B. The receipt350 not only summarizes the transaction and the execution and failureconditions, but also provides a transaction identifier. The transactionidentifier may be provided by the customer to various persons by thecustomer 104, with a request that they act as contributing parties 116.This identifier may then be requested by the host system through aninterface with the contributing parties 116 to direct theircontributions appropriately to the pooled transaction. In addition, ininstances where the customer 104 has provided a contribution at the timeof initiation, the receipt may include a specific acknowledgment of theamount received and an instruction to print the receipt for possibletax-filing purposes. A print button 352 may be provided to print a copyof the receipt when the pooled transaction is initiated at a transactiondevice, or may be printed by the customer 104 locally when a remoteinterface is used.

FIG. 4 provides a schematic illustration of a structure that may be usedto implement the host system 104. FIG. 4 broadly illustrates howindividual system elements may be implemented in a separated or moreintegrated manner. The host system 104 is shown comprised of hardwareelements that are electrically coupled via bus 426, including aprocessor 402, an input device 404, an output device 406, a storagedevice 408, a computer-readable storage media reader 410 a, acommunications system 414, a processing acceleration unit 416 such as aDSP or special-purpose processor, and a memory 418. Thecomputer-readable storage media reader 410 a is further connected to acomputer-readable storage medium 410 b, the combination comprehensivelyrepresenting remote, local, fixed, and/or removable storage devices plusstorage media for temporarily and/or more permanently containingcomputer-readable information. The communications system 414 maycomprise a wired, wireless, modem, and/or other type of interfacingconnection and permits data to be exchanged with the transaction devices120, the Internet interface 128, the DTMF interface 132, the cableinterface 136, and the financial institutions 124 to implementembodiments as described above.

The host system 104 also comprises software elements, shown as beingcurrently located within working memory 420, including an operatingsystem 424 and other code 422, such as a program designed to implementmethods of the invention. It will be apparent to those skilled in theart that substantial variations may be made in accordance with specificrequirements. For example, customized hardware might also be used and/orparticular elements might be implemented in hardware, software(including portable software, such as applets), or both. Further,connection to other computing devices such as network input/outputdevices may be employed.

Thus, having described several embodiments, it will be recognized bythose of skill in the art that various modifications, alternativeconstructions, and equivalents may be used without departing from thespirit of the invention. Accordingly, the above description should notbe taken as limiting the scope of the invention, which is defined in thefollowing claims.

1 A method for processing a financial transaction, the methodcomprising: receiving a set of conditions at a host system that definecircumstances for execution of the financial transaction; collectingfunds for each of a plurality of partial payments prior to satisfactionof the set of conditions, wherein at least two of the partial paymentsare collected from different persons; receiving at the host systeminformation on the collection of the funds; and accumulating thecollected funds for support of the financial transaction untilsatisfaction or failure of the set of conditions.